A Virtual Laboratory Environment for Tertiary Educational Institutions

Computer laboratories at tertiary educational institutions need to be flexible and easy to manage, as they typically cater for a wide range of needs. This article describes how a particular virtual laboratory environment can be extended to include server-based virtualization. It explores some of the major technical challenges of implementing one particular hypervisor and associated management software, specifically to deploy a set of virtual machines that form part of a particular course, as this is one of the envisaged uses for this technology. It goes on to suggest a number of solutions and includes two scripts that can serve as templates for automating the creation and removal of sets of student virtual machines. DOI: 10.4018/jbdcn.2012040102 International Journal of Business Data Communications and Networking, 8(2), 18-40, April-June 2012 19 Copyright © 2012, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited. have employed virtualization over the past nine years successfully to provision systems that form an integral part of a wide range of courses in their own tertiary institution. According to a recent survey 74% of organisations employ server-based virtualization and will make this their top IT priority over the next twelve to eighteen months (Enterprise Strategy Group, 2011). At present virtualization is used extensively in industry for software testing, and is a “key targeted scenario” for the Hyper-V virtualisation platform (Kelbley & Sterling, 2010). For example, developers testing software would find it useful to be able to access a laboratory environment and make use of ready-built template virtual machines. In a similar way, students can work on machines allocated to them or even provision machines for themselves. Server-based virtualisation is now a pervasive part of the information technology landscape, but implementing it for the purpose of provisioning virtual machines for students is still unusual. A number of commercial organisations offer server-based virtual laboratory environments, including Element K (2012), Transcender (2012), and Wiley and Sons (2012), but these are proprietary systems established for the express purpose of providing private training and preparing candidates for vendor-specific certification examinations. The solutions themselves are not generally available and certainly not something academic staff in tertiary institutions can use. The current laboratory environment in the authors’ institution works well but has some important limitations due in large part to its use of local workstation-based (type 2) virtualisation. These limitations can be circumvented by implementing some form of server-based virtualisation, but this raises many questions related to how server resources are best allocated and managed, and the role, extent and nature of automation. This article reports on some of the technical challenges involved in implementing Hyper-V in a particular laboratory environment and the way in which scripting can be used to automate the creation and removal of sets of virtual machines provided as part of third-party courseware (for the purposes of this article, the term “lab” refers to a structured series of tasks designed to achieve specific learning outcomes, as opposed to the term “laboratory”, which refers to an entire environment designed for the purpose of learning). THE CURRENT ENVIRONMENT All the physical workstations in the current laboratory environment, a network called “TechLabs,” have VMware Workstation installed on them. These machines connect to two distinct networks, one physical, and one virtual. Each machine has two physical network adapters: one dedicated to what is a normal, conventional network, called the “Blue” network, the other dedicated to connecting virtual machines, called the “Red” network. These two networks are distinct physical and logical entities, with one set of switches for the Blue network and another for the Red network, and the TCP/IP stack of the physical machine being used on the Blue network and the TCP/IP stack of the virtual machine(s) being used on the Red network. The Red network comprises of a number of virtual local area networks (VLANs), making it in effect not one network, but a set of networks. What this means is that student virtual machines may run a wide range of operating systems as well as connect to a number of networks, some localised to the individual physical machine, one limited to the classroom, one that can access central servers on the Red local area network, one that connects to the Internet by means of network address translation and one that connects to the Internet through conventional routing, the latter made possible by students being temporarily allocated a public Internet Protocol version 4 (IPv4) address. This infrastructure enables students and staff to use virtual machines to connect to various networks in different ways and provides an environment that somewhat resembles that of so-called “real-world” industry. While all this currently works well, it does impose some major limitations. At present, all 21 more pages are available in the full version of this document, which may be purchased using the "Add to Cart" button on the product's webpage: www.igi-global.com/article/virtual-laboratory-environmenttertiary-educational/70208?camid=4v1 This title is available in InfoSci-Journals, InfoSci-Journal Disciplines Communications and Social Science. Recommend this product to your librarian: www.igi-global.com/e-resources/libraryrecommendation/?id=2